Skip to main content

rApp-xApp Communication

ODIN and rApps do not have direct access to collect data or take action in the RAN. Instead, these responsibilities are delegated to xApps.

Execution Delegation Model​

ODIN follows a separation-of-responsibilities model between rApps, ODIN, and xApps:

Policy flow chart

🔹 rApps (Intent Definition)​

  • Define high-level objectives (e.g., SLA assurance, energy efficiency)
  • Initiate policy deployment by creating a PolicyObjectInformation
  • Specify:
    • nearRTRIC ID: Target Near-RT RIC
    • Policy Type ID: Indicates the required xApp
    • PolicyObject: Contains the policy logic and configuration details to be enforced by the xApp

🔹 Non-RT RIC (ODIN)​

  • Parses the received PolicyObjectInformation
  • Determines:
    • The target Near-RT RIC
    • The appropriate xApp based on the policy type
  • Deploys or reuses the corresponding xApp as needed
  • Forwards the PolicyObject to the xApp via the A1 interface
  • Returns a Policy ID to the rApp for reference and tracking

🔹 xApps (Execution Agents)​

  • Receive policies through the A1 interface
  • Perform:
    • Data collection
    • Local control decisions
    • RAN control actions
  • Optionally report feedback to ODIN via A1

This model ensures rApps define what needs to be done, ODIN decides how and by whom, and xApps execute the tasks in the RAN.

Example of Policy Enforcement in RAN​

The following figure shows how a policy is enforced in the RAN, from high-level SLA objectives to low-level resource allocation.

Policy Enforcement Flow

  1. SLA (Service-Level Agreement):
    The process begins with an SLA requirement that specifies the expected network behavior or performance for a user, slice, or service.
  2. rApp (Policy Definition):
    The rApp translates SLA objectives into bandwidth requirements.
  3. xApp (Policy Execution Plan):
    Converts bandwidth needs into a % Physical Resource Block (PRB) allocation based on KPIs.
  4. RAN Function:
    Maps the percentage to an exact PRB count.
  5. MAC Scheduler:
    Computes Transport Block Size (TBS) based on PRBs.

R1 Interface (rApp to ODIN)​

The rApp SDK is a Python library that simplifies the design, development, and onboarding of rApps within the ODIN platform.
It provides a high-level abstraction—similar in spirit to the R1 interface—allowing developers to build rApps without dealing directly with low-level Kubernetes APIs (e.g., Custom Resources).

Supported Services (as of now)​

🔹 A1 Services​

  • Define and manage policies via the A1 interface
  • Create and manage PolicyJob resources

🔹 Monitoring Services​

  • Request monitoring data from the RAN
  • Create and manage MonitoringJob resources

🔹 OAM Services​

  • Interact with OAM functions for network element management
  • Execute operational tasks through exposed interfaces

A1 Interface (ODIN to xApp)​

ODIN communicates with xApps through a standardized, HTTP-based A1 interface, which each xApp must implement.

Required Endpoints:​

  • PUT /a1-p/policy → Mandatory: Used by ODIN to push new policies to the xApp.
  • GET /a1-p/feedback → Optional: xApp may expose this to provide runtime feedback on policies.
  • DELETE /a1-p/policy → Mandatory: Used to remove a policy from the xApp when it is no longer needed.

This interface allows ODIN to dynamically configure, update, or decommission xApps based on rApp-defined intents.

Note:
The JSON content exchanged between ODIN and xApps is compliant with the O-RAN A1 specifications. However, the URL path structure used by ODIN is not fully compliant.

According to the O-RAN A1 specification, parameters like PolicyTypeId and PolicyId should appear in the URL path to enable routing by the Near-RT RIC:

/A1-P/v2/policytypes/{policyTypeId}/policies/{policyId}

In our implementation, the Near-RT RIC (FlexRIC) does not perform internal routing. FlexRIC operates more like a lightweight application than a cluster-based platform.

As a result, ODIN uses a static and tiny URI for simplicity and direct delivery to the target xApp:

/A1-P/policies

In the next release, we plan to extend the A1 interface to support full path-based routing and compliance with the O-RAN A1 standard, as the RIC architecture evolves.